Analysis

During undo tablespace truncation in MySQL, when the target undo tablespace has grown significantly large, the undo_spaces_lock (a read-write lock) experiences severe contention, as demonstrated below

The undo_spaces_lock safeguards concurrent access to the following data structures:

• undo::spaces::m_spaces
• undo::space_id_bank
• undo truncation logs

Performance Impact:
When the purge coordinator thread holds the undo_spaces_lock in write mode, all DML foreground threads become blocked, resulting in measurable throughput degradation during this period.

Critical Section Analysis:
The purge coordinator thread pool acquires the lock solely to protect:

• undo::space_id_bank
• undo truncation logs
  (Note: It never modifies undo::spaces::m_spaces)

DML foreground threads require the lock only to ensure: read consistency of undo::spaces::m_spaces
(Key Insight: No inherent logical conflict exists between these thread types)

Optimization Strategy

1. Snapshot Mechanism:

• After obtaining the write lock, the purge coordinator creates a snapshot of undo tablespaces
• DML threads then query this snapshot directly, eliminating their need for read locks

2. Fine-grained Synchronization:

• Replaces coarse-grained locking with atomic operations for:
  • Version tracking
  • State synchronization
• Maintains consistency between purge coordinator and DML threads

Figure 1 - current undo_spaces_lock (Before)

Figure 2 - The optimized undo_spaces_lock (After)